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Introduction to White Pages Services based on X.500 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document aims at organisations who are using local and global 
electronic communication on a day to day basis and for whom using an 
electronic White Pages Service is therefore indispensable. 


The document provides an introduction to the international ITU-T 
(formerly CCITT) X.500 and ISO 9594 standard, which is particularly 
suited for providing an integrated local and global electronic White 
Pages Service. 


In addition a short overview of the experience gained from the 
Paradise X.500 pilot is given. References to more detailed 
information are included. 


The document should be useful for managers of the above mentioned 
organisations who need to get the necessary executive commitment for 
making the address information of their organisation available by 
means of X.500. 
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1. Introduction 


Due to the tremendous growth and development of international 
computer networks we have nowadays the possibility to overcome - 
without having to travel - geographical distances when working 
together with other people. Besides the possibility of using the 
telephone we may use electronic data exchange to discuss working 
documents, new ideas, plans or whatsoever. One of the most popular 
means for this is electronic mail, which can be used to exchange 
all kinds of electronic data: from informal pure text messages to 
formatted and multi-media documents. 


As the number of people connected to computer networks grows (and 
it does continuously, it is at least doubling each year!), it 
becomes more difficult to track down people’s electronic (mail) 
addresses. Hence, in order to make global communication over 
computer networks work, a global White Pages service is 
indispensable. Such a service should of course provide people’s 
electronic mail addresses, but could also easily contain telephone 
and fax numbers and postal addresses. 


Currently, one technical solution for a globally distributed 

White Pages service is X.500 and there exists an international 
infrastructure based on X.500 technology called ’Paradise’ 
(Piloting An inteRnationAl DIrectory SErvice), which contains about 
1.5 million entries belonging to persons and 3,000 belonging to 
organisations. Worldwide 35 countries are involved. Paradise is 
also a project of the EC. The project continues until September 
1994. Afterwards its operational tasks will be taken over by a 
European service provider for the R&D community (DANTE). 


The goal of Paradise and related national initiatives is to 
stimulate and extend the use of the X.500 White Pages service. 
Within the pilot attention is paid to technical and organisational 
aspects. The Paradise infrastructure is mainly based on the 
Internet Protocol. The specific issues that are related to the use 
of the Internet Protocol for X.500 can be found in [5]. 


In the decision process of joining the international X.500 
infrastructure and opening (part) of the local (address) 
information to the outside world, it is important that an 
organisation fully understands the technical and organisational 
issues that are involved. 


This document tries to be of help in this matter first by 
explaining the main concepts of X.500 (section 2) and subsequently 
by pointing out its benefits (section 3), the organisational 
aspects that are involved (section 4), and for which other 
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applications the X.500 infrastructure may be used in the near 
future (section 5). 


2. Concept of X.500 


The X.500 standard describes a so-called ‘’Directory Service’, which 
can be used for all types of electronic directories. This document 
focusses on the use of X.500 for a global White Pages Directory. 
The concept of X.500 may roughly be divided in the ’/Directory 
model’ and the ’Information model’. 


2.1 Directory model 


X.500 uses a distributed approach to achieve the goal of a global 
Directory Service. The idea is that local (communication oriented) 
information of an organisation is maintained locally in one or more 
so called Directory System Agents (DSA’s). ’Locally’ is a flexible 
expression here: it is possible that one DSA keeps information of 
more than one organisation. A DSA essentially is a database: 


- in which the information is stored according to the X.500 
standard (see section 2.2), 


- that has the ability, where necessary, to exchange data 
with other DSA’s. 


Through the communication among each other the DSA’s form the 
Directory Information Tree (DIT). The DIT is a virtual hierarchical 
datastructure consisting of a ’root’, below which ’countries’ are 
defined. Below the countries (usually) ’organisations’ are defined, 
and below an organisation ’persons’, or first additional 
‘organisational units’, are defined (see the simplified illustration 
below where only three countries and no organisational units are 
presented). The DIT is a representation of the global Directory. 
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Each DSA holds a part of the global Directory and is able to find 
out, through the hierarchical DIT structure, which DSA holds which 
parts of the Directory. 


The standard does not describe how to distribute different part of 
the Directory among DSA’s. However, the information corresponding to 
a single node of the DIT (i.e., a country, organisation, person) 
cannot be distributed over several DSA’s. In practice a large 
organisation will maintain one or more DSA’s that hold its part of 
the Directory. Smaller organisations may share a DSA with other 
organisations.The distribution among the DSA’s is totally transparent 
to the users of the Directory. 


A user of the Directory can be a person or a computer. A user 
accesses the Directory through a so-called Directory User Agent 
(DUA). The DUA automatically contacts a nearby DSA by means of which 
the user may search or browse through the DIT and retrieve 
corresponding information. A DUA can be implemented in all sorts of 
user interfaces. Therefore users may access the Directory through 
dedicated DUA interfaces or for example e-mail applications. 
Currently most DUA nterfaces to be used by persons are dedicated, but 
it is expected that in the near future a lot of DUA interfaces will 
be integrated with other applications. 


2.2 Information Model 


Besides the Directory model, the X.500 standard also defines the 
information model used in the Directory Service. 


All information in the Directory is stored in ’entries’, each of 
which belongs to at least one so-called ’object class’. In the White 
Pages application of X.500, on which we focus here, object classes 
are defined such as ’country’, ’organisation’, ‘’organisational unit’ 
and ’person’. 


The actual information in an entry is determined by so-called 
‘attributes’ which are contained in that entry. The object classes to 
which an entry belongs define what types of attributes an entry may 
use and hence what information is specific for entries belonging to 
that object class. The object class /’person’ for example allows 
attribute types like ‘common name’, ’telephone number’, and ’e-mail 
address’ to be used and the object class ’organisation’ allows for 
attribute types like ’organisation name’ and ’business category’. 
Dependent on its type an attribute can take one or more values. 


To specify the name of an entry in the DIT, at least one attribute 


value of the entry is used. The entry of a person is usually named 
after the value of the attribute type ’common name’. The name of an 
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entry must be unique on the same level in the subtree of the DIT to 
which the entry belongs. 


An example of an entry belonging to the object class ’person’ is: 


Attribute type Attribute value 
Object Class: top 
person 
Common Name: Thomas Lenggenhager 
T. Lenggenhager 
Surname: Lenggenhager 
Postal Address: SWITCH 


Limmatquai 138 
CH-8001 Zuerich 


Telephone Number: +41 1 268 1540 
Facsimile Telephone Number: +41 1 268 1568 
Mail: lenggenhager@switch.ch 


This entry corresponds to the node in the DIT that occurs below the 
node of the organisation ’SWITCH’ and is named after the first value 
of the attribute type ’common name’: ’Thomas Lenggenhager’. 


3. Benefits of X.500 


Why should one use X.500 for a local White Pages service? Here are 
some good arguments: 


— The distributed character of the service. A large 
organisation may distribute the responsibility for the 
management of the information it presents through X.500 by 
distributing this information over several DSA’s (without 
losing the overall structure) 


-— The flexibility of the service. Besides for public purposes, 
X.500 may also be used for specific private Directory Service 
applications. Whereas the definitions of the DIT, object 
classes and attribute types of the public White Pages 
information within an organisation have to conform to those 
of the rest of world, the internal applications may use their 
own DIT structure and their own definitions of object classes 
and attributes (the values being only visible within (a part) 
of the organisation). Nevertheless one local infrastructure 
can be used for both the public and private computers. 
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- Good alternative for paper Directories. The provision of 
White Pages services based on X.500 may be a good alternative 
for paper directories, because the latter directories are 
rarely up-to-date (due to the printing costs) and because 
X.500 not only can be used by humans but also by 
applications. 


Some important arguments in favour of X.500 for global use are: 


- By its distributed nature X.500 is particularly suited for a 
large global White Pages directory. Maintenance can take 
place in a distributed way. 


- Good searching capabilities. X.500 offers the possibility to 
do searches in any level or in any subtree of the DIT. In 
order to do a search an attribute type together with a value 
have to be specified. Then the Directory searches for all 
entries that contain an attribute of that type with the given 
value. For example one can search for all persons in an 
organisation having a particular common name, or all 
organisations within a country that have telecommunications 
as their business category. It is up to the organisations 
that maintain the DSA’s to decide who may perform which 
searches and also how many levels deep a search may be. 


Searches can be done on the basis of an exact or approximate 
match. It is worthwile to note that distributed searches 
(that need connections to a lot of DSA’s) may be expensive 
and are generally not encouraged. 


-— There are DUA interfaces for the White Pages service 
availablefor all types of workstations (DOS, Macintosh OS, 
Unix). For an overview of X.500 available software see 
RFC 1292 [2] or updates of this document. 


- X.500 is an international standard. Using a standard 
obviously means less problems with interoperability and 
interworking.Also the standard is updated according to 
practical experience. 


4. Organisational aspects of X.500 (experience from Paradise) 


The organisational aspects involved in operating a local X.500 (or 
any other electronic) Directory can roughly be divided in three 
sub-aspects:datamanagement, legal issues and cost aspects. With 
respect to cost aspects there is no publicly known model or 
experience at the moment. 
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Therefore the focus in this document is on datamanagement and legal 
issues. 


Data management refers to issues that are related to inserting 
appropriate information into the Directory and keeping it up to date. 


From the experience of participants in Paradise we obtain that the 
following items are of first importance: 


- Executive commitment. Without this it is almost impossible to 
create an organisation wide up-to-date electronic Directory. 


- Structure of the local DIT. In joining the international 
infrastructure an organisation has to conform to some rules 
for the local DIT structure as presented to the global X.500 
infrastructure. A recommendation on how to structure a local 
DIT and how to use the available attributes can be found in 
[7]. The most important recommendation in the latter document 
is to keep the local part of the DIT as simple (flat) as 
possible. The reason is that users from outside the 
organisation may otherwise have difficulties in finding 
entries of persons within the organisation (searches in the 
DIT are often only allowed one level deep). 


- Attributes to be used. For the existing infrastructure the 
objects and associated attributes that are globally used, are 
documented in [1]. 


—- Sources of the data. An organisation has to find out where to 
get what kind of data and develop procedures for uploading 
its DSA(’s). 


- Delegating responsibilities for updates. Procedures have to 
bedeveloped for updates of the local Directory. These 
procedures have to include delegation of responsibilities. 


— Security procedures. Rules have to be set for access and 
security. Who may contact the DSA? Who will have access to 
which subtrees and what attributes? 


A study of the legal consequences of presenting (address) information 
via X.500 lead to the main conclusion that in Europe an organisation 
has to formally register its data collections. Registration implies 
defining a goal for the application. This has to be done for the 
White Pages service as well as for any deviating local application of 
X.500. However, the different national laws may differ with respect 
to legal restrictions. For more information on this subject we refer 
to "Building a Directory Service, Final Report test phase SURFnet 
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- 


X.500 pilot project", E. Huizer, SURFnet B.V., Utrecht NL, 1994. 
(copies available from SURFnet B.V.) 


Among the Paradise members there are several pilots running at the 
moment with the goal to evaluate the organisational aspects. Case 
studies coming from these pilots will be documented. 


Small or medium size organisations that have not too many entries to 
insert in the Directory may use one of the different national 
initiatives concerning a ‘central DSA’. These central DSA’s are 
operated by national service providers and contain the White Pages 
information of a lot of small and medium size organisations. For 
organisations in countries without such a national service there is 
also a European central DSA (Paradise) and an American central DSA 
(InterNIC). It is worth noting that the central DSA services are only 
technical services, i.e., a participating organisation still has to 
cover the organisational issues. However, part of a central DSA 
service may be consultancy with respect to datamanagement and legal 
issues. 


5. Applications of X.500 


Besides for White Pages, X.500 can be useful for all kinds of 
distributed information storage from which humans or machines can 
benefit. Examples that are likely to use X.500 in the near future 
are: distribution list mechanism, public key distribution for Privacy 
Enhanced Mail (PEM), routing of X.400 messages, distribution of EDI 
identifiers, etc. For more information we refer to [7]. Below the 
first three applications are briefly discussed. 


The distribution list mechanism uses X.500 for finding the e-mail 
addresses of the persons that have subscribed to a list. The 
distributed approach of X.500 makes it possible that people change 
their e-mail address without having to change their subscription to 
distribution lists. 


PEM (see a.o. [8] or [4]) uses a public key mechanism for exchanging 
secure e-mail messages. For example: one will be able to end a secure 
message by encrypting a message with the publicly known (public) key 
of the recipient. Only the recipient of the message can decipher the 
message using his/her private key. In order to make such a mechanism 
work one must have access to the public keys of all possible 
recipients. X.500 can be used for this purpose. 


At this moment a world-wide pilot is running in which X.400 routing 
is done by means of X.500. X.400 MTA’s use special DUA’s to find via 
the Directory the MTA’s to which the recipients of a message want 
their mail to be delivered. The distributed approach of X.500 will 
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mean much less routing management (currently tables are used that 
have to be updated/exchanged periodically). 
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Security Considerations 


Security issues are not explicitly discussed in this memo. 
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